-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement actions #21937
Implement actions #21937
Conversation
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't intend to review other parts of the code, but this was too notable.
Is it also intended to create documentation for this?
Is "bots" the name of the whole CI/CD feature? If yes, then I think that's not a good name because bots are usually something different (machine controlled user accounts). |
It's not only CICD, that's why we don't name it Gitea CI. We have a name discuss in #13539, maybe automate is a better name. |
This comment was marked as resolved.
This comment was marked as resolved.
Provide a new type to make it easier to parse a ref name. Actually, it's picked up from #21937, to make the origin PR lighter. Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, after a lot of problems, I've finally been able to successfully test the most critical parts.
I still made some observations:
as you can see here, , the branch still has the BranchPrefix
.
Additionally, only about 5% of the time when I click on the Rerun
action, it will actually be rerun. And I can see at the same time that the runner does not get any new tasks while polling.
The last problem I noticed is that canceled workflows are displayed with the same color as failed workflows, but there is no indication anywhere that the reason for this is that the task was canceled.
Lastly, as you might know already, I absolutely dislike the DBFS.
I also noticed some minor things which you can see in the history of all comments on this PR.
However, as it seems at the moment, these things will all be postponed for later PRs.
Once this PR is merged, I'll create a follow-up issue where I post everything that was postponed here to merge it in time for 1.19.
I would like to suggest reviewers to always provide alternative and feasible solutions when something is disliked. Otherwise, there will be non-sense arguments, the author won't know what to do. |
This is expected behavior. Use EDIT |
I've done the work of the 🤖 now myself. |
Okay, now I feel bullied. |
@delvh You did work well. Thank you very much!!! |
make LG-TM work |
great work y'all! |
That sentence is meanst as "large public instances such as Codeberg should probably not enable it", mainly because of the stress it places on that system. |
If triggered by PR, the ref should be `pull/<index>/head` instead of `repo.DefaultBranch`. And improve UI: <img width="493" alt="image" src="https://user-images.githubusercontent.com/9418365/215731280-312564f2-2450-45d0-b986-1accb0670976.png"> Related to #21937.
#21937 implemented only basic events based on name because of `act`'s limitation. So I sent a PR to parse all possible events details in https://gitea.com/gitea/act/pulls/11 and it merged. The ref documentation is https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows This PR depends on that and make more detail responses for `push` events and `pull_request` events. And it lefts more events there for future PRs. --------- Co-authored-by: Jason Song <i@wolfogre.com>
Hey! My understanding is that this is merged to main. I have updated the Docker image earlier today, from the latest release. I have:
But Gitea 1.18.4 (shows on the footer) still doesn't show anything about Actions/Runners. Am I doing anything wrong, or does this release not yet include Actions at all? Thanks! |
If you are using docker, using dev currently not 1.18.4. |
Close #13539.
Co-authored by: @lunny @appleboy @fuxiaohei and others.
Related projects:
Summary
The target of this PR is to bring a basic implementation of "Actions", an internal CI/CD system of Gitea. That means even though it has been merged, the state of the feature is EXPERIMENTAL, and please note that:
Please comment on #13539 if you have any different product design ideas, all decisions reached there will be adopted here. But in this PR, we don't talk about naming, feature-creep or alternatives.
gitea-actions
will become a reserved user name. If a user with the name already exists in the database, it is recommended to rename it.Some important reviews
DEFAULT_ACTIONS_URL
inapp.ini
for?/api/v1
prefix?gitea-actions
bot?What it looks like
Manage runners
List runs
View logs
How to try it
1. Start Gitea
Clone this branch and install from source.
Add additional configurations in
app.ini
to enable Actions:Start it.
If all is well, you'll see the management page of runners:
2. Start runner
Clone the act_runner, and follow the README to start it.
If all is well, you'll see a new runner has been added:
3. Enable actions for a repo
Create a new repo or open an existing one, check the
Actions
checkbox in settings and submit.If all is well, you'll see a new tab "Actions":
4. Upload workflow files
Upload some workflow files to
.gitea/workflows/xxx.yaml
, you can follow the quickstart of GitHub Actions. Yes, Gitea Actions is compatible with GitHub Actions in most cases, you can use the same demo:If all is well, you'll see a new run in
Actions
tab:5. Check the logs of jobs
Click a run and you'll see the logs:
6. Go on
You can try more examples in the documents of GitHub Actions, then you might find a lot of bugs.
Come on, PRs are welcome.
See also: Feature Preview: Gitea Actions